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This  is  the  third  monthly  progress  report  for  the  Multispectral  High  fidelity  RADAR 
Scene  Generator  SBIR  (Phase  1),  Contract  #  Nd8335-99-C-0126. 


1.0  Work  Summary 

Work  that  was  done  between  Apr.  12  and  May.  12  included  some  of  the  items  that  were 
intended  to  be  addressed  in  the  previous  reporting  period.  The  real  time  RADAR  interface 
contribution  into  the  RADAR  Scene  Generator  (RSG)  was  defined  and  the  connection  points 
for  all  the  interface  attributes  were  identified.  Additionally,  circuit  diagrams  for  a  real  time 
version  of  the  RSG  were  developed.  The  RSG  is  able  to  be  implemented  as  a  desktop 
analytical  simulator  as  well  as  a  real  time  RADAR  interactive  device.  The  desktop  analytical 
simulator  can  be  run  on  a  standard  PC  and  is  therefore  uninteresting  from  a  hardware 
configuration  standpoint.  The  real  time  model  has  computational  constraints  placed  on  it  as 
well  as  interactivity  requirements  that  demand  attention  at  the  microsecond  level.  This  is 
where  the  hardware  interconnection  speeds  and  data  transfer  rates  are  directly  responsible  for 
performance.  This  report  covers  the  tradeoff  space  that  was  investigated  and  the  resulting 
configuration. 

2.0  Schedule 

As  anticipated  in  the  proposal,  a  full  schematic  of  the  real-time  RSG  implementation 
has  been  developed.  The  RADAR  specific  portion  of  the  RSG  has  been  left  for  definition 
when  a  ^ecific  target  RADAR  has  been  picked. 

3.0  Studies 

An  effective  interface  for  real-time  RSG  implementation  was  developed.  This  consists  of  2 
portions...  (1)  signals  to  the  RADAR  and  (2)  signals  from  the  RADAR. 

RSG  signals  to  RADAR 

When  attached  to  a  RADAR,  the  RSG  has  to  be  able  to  interact  with  the  signal 
processor  and  selected  portions  of  the  receiver  chain.  The  most  convenient  plxe  to  interact  is 
one  where  the  interconnections  are  minimized.  This  approach  tends  to  affect  existing  hardware 
to  the  least  degree. 


All  RADARS  have  an  intermediate  frequency  (IF)  where  the  matched  filtering  takes 
place.  This  IF  consists  of  the  teal  time  RADAR  data  downconverted  for  handling 
convenience.  In  the  case  of  modem  RADARs,  this  IF  is  often  directly  digitized  so  as  to  avoid 
the  pitfalls  of  in-phase  (I)  and  quadrature  ((^  channel  imbalance  that  has  to  be  maintained  in 
the  receiver  chain.  The  baseband  conversion  is  titen  done  in  the  digital  domain  where  signal 
purity  can  be  maintained  more  easily. 

The  nature  of  RSG  signal  generation  requires  that  there  be  individually  controllable  I  & 
Q  components  involved  to  create  the  composite  signal  seen  by  the  RADAR.  Concq)tually,  the 
easiest  interface  to  the  RADAR  is  at  the  digital  level  where  the  I  &  Q  components  are  still 
pristine.  However,  the  data  bandwidth  associated  with  such  a  connection  makes  it  impractical. 
For  example,  the  digital  data  bandwidth  is  determined  by  the  maximum  signal  bandwidth,  and 
in  the  case  of  the  example  chosen  in  the  first  progress  report,  the  hypothetical  RADAR  has  a 
10  MHz  “wideband”  mode  used  for  precision  tracking.  The  10  MHz  would  imply  that  I  &  Q 
samples  had  to  be  injected  at  a  10  MSPS  rate,  where  each  sample  was  2  bytes  wide  (16  bit 
resolution  usually  covers  the  most  stringent  application). 

This  means  that  a  40  MBPS  data  channel  has  to  be  provided  along  with  all  the 
synchronizing  signals  in  order  to  test  such  a  RADAR.  The  implementation  for  such  an 
information  channel  requires  that  the  RSG  be  in  close  proximity  to  the  RADAR  signal 
processor  (typically  6  ft.  or  less)  or  that  there  be  provisions  for  re-synchronizing  hardware  at 
various  points  along  the  way.  Further,  that  signal  processor  boards  in  the  RADAR  be 
modified  to  accept  an  alternate  source  for  such  broadband  digital  data...  for  each  channel  of  a 
multi-channel  RADAR. 

This  is  where  IF  injection  proves  to  be  the  most  practical  2q)proach.  In  the  case  of  a 
multi-channel  RADAR,  each  receive  channel  has  just  1  IF  connection  (usually  co-axial) 
associated.  On  the  RSG  end  this  means  digital-IF  conversion,  but  this  step  allows  the  RSG  to 
be  compatible  with  virtually  all  RADARs  in  the  field.  Prudent  design  of  the  IF  conversion 
hardware  would  provide  the  complex  RADAR  signal(s)  at  a  nominal  IF  frequency.  Further, 
the  IF  conversion  unit  would  be  Ae  synchronizer  that  coordinated  the  RSG  ouq)ut  with  the 
RADAR  clocks.  Each  RADAR  {^plication  would  have  associated  a  frequency  converter 
designed  to  tailor  the  RSG  ouq)ut  to  a  coherent  reference  signal  provided  by  tiie  RADAR. 

Control  signals  from  RADAR 

The  RSG  is  required  to  interact  with  the  RADAR  on  a  real  time  basis.  To  so  do,  a  set 
of  control  signals  are  required  from  the  RADAR: 

Time  synchrony  -  These  are  the  set  of  signals  that  will  be  required  to  synchronize  the 

RADAR  operations  with  the  RSG. 

Main  bang  -  signal  representing  the  trigger  to  the  RADAR  transmitter.  This  signal  will 
be  fed  to  the  digital-to-IF  conversion  hardware  so  that  it  can  “play  back”  its 
buffer,  which  has  been  loaded  by  the  digital  processor  portion  of  the  RSG. 


G)inmand  data  transfer  -  this  signal  consists  of  a  set  of  £q)riori  data  protocol  TBD)  that 
originates  in  the  “beam  scheduler”  (or  equivalent)  portion  of  Ae  RADAR.  This 
data  describes  the  settings  for  the  antenna  (if  it  is  a  phased  array)  and  any  other 
equipment  in  preparation  for  the  next  measurement  interval.  The  ejected 
s^riori  margin  at  this  point  is  approximately  3  msec.  Depending  on  the 
RADAR,  this  set  of  signals  can  range  from  the  very  simple...  such  as  a 
frequency  code  for  a  continuous  admuth  search  RADAR...  to  the  other  extreme 
where  the  RADAR  dynamically  selects  waveforms,  STC  contours,  processing 
bandwidths,  transmit  power  levels  and  antenna  beam  positions. 

Status  information  back  to  the  RADAR  -  most  modem  RADARs  have  continuous 
monitoring  of  the  command  data  stream  to  the  hardware.  In  the  situation  that 
the  integrity  of  this  data  link  is  compromised,  the  RADAR  reports  a  catastrophic 
fault  and  usually  aborts  its  mission. 

Digitizing  clock  -  used  by  the  A/D  to  qmchronize  the  live  data  collection  process. 

This  signal  is  fed  directly  to  the  digital-to-IF  conversion  hardware  where  it  is 
used  to  clock  out  the  digital  data  buffer.  As  a  result  of  the  apriori  RADAR 
settings,  the  RSG  digital  hardware  has  filled  the  data  buffer  in  the  IF  conversion 
device. 

Antenna  synchrony.  The  beam  position  commands  have  been  addressed  in  the 
“command  data  transfer”  section  above.  Some  RADARs  have  dynamic 
selection  of  antenna  aperture  weights  for  various  mission  dictated  modes.  The 
RSG  requires  this  specific  information  so  the  £q)propriate  sidelobe  contributions 
(in  various  EW  modes)  or  the  changing  beamwidths  (in  precision  track  modes) 
can  be  correctly  reflected  in  the  live  data. 

Processing  synchrony  -  this  set  of  interfaces  coordinates  the  RSG  ouqiut  with  the  signal 
processor  state.  For  example,  some  RADARs  have  wideband  precision  track 
modes  where  a  “track  gate”  has  been  established  around  the  target,  and  all  the 
processing  resources  have  been  focused  to  this  track  gate  to  maximize  the 
fidelity  of  the  process.  The  same  principles  apply  to  the  RSG.  With  the  priori 
knowledge  of  this  track  gate,  the  ^G  can  abandon  the  rest  of  the  range  trace 
and  focus  its  processing  resources  on  processing  wide  band  clutter  models 
within  the  track  gate  only,  resulting  in  higher  fidelity  environment  emulation. 

RSG  hardware  tradeoff  issues. 

There  is  a  variety  of  signal  processor  hardware  available  on  the  market.  After 
performing  an  initial  survey  of  the  market,  the  field  of  qualifying  candidates  was: 

Octagon  Systems  in  Westminster,  Colorado  -  embedded  PC  solutions 
Eonic  Systems  in  Herndon,  Virginia  -  real-time  DSP  and  RISC  solutions 
Alta  Technology  in  Sandy,  Utah  -  parallel  networking  {^plications 
Motorola  in  El  Segundo,  California  -  Power  PC  networked  processors 
Acromag  in  Wixom,  Michigan  -  Industrial  I/O  solutions  for  VME  and  cPCI 


Spectrum  Signal  Processing  in  Burnaby,  BC,  Canada  -  real-time  DSP  for  VME  &  cPO 

Pentek  in  Upper  Saddle  River,  NJ  -  DSP  &  data  acquisition  for  a  variety  of  data  buses 

CSPI  in  Billerica,  Massachusetts  -  multi  processor  compute  nodes 

Some  of  the  issues  that  were  considered  in  arriving  at  a  recommended  solution  were: 

1)  Hardware  maturity  -  what  was  available  on  the  market,  how  long  the  architecture  had 
been  fielded,  what  the  bus  infrastmcture  was  &  where  it  was  migrating  and  what  role 
the  vendor  had  in  providing  a  working  solution  (rather  than  a  group  of  parts  mounted 
on  aboard). 

2)  Software  development  environment  -  maturity,  ease  of  use,  code  portability  and 
integration  with  other  development  environments.  Typically,  the  DSP  has  a  set  of 
unique  software  tools  that  have  to  integrate  with  an  overall  development  platform  such 
as  Unix,  Windows,  DOS  etc. 

3)  Tech  Support  availability  -  time  zone  conpatibility  for  voice  support,  and  additional 
fomms  for  other  forms  of  tech  support...  E-mail,  Web  site.  Bulletin  board  etc... 

4)  Compatibility  with  existing  Malibu  Research  RES  (RADAR  Environment  Simulator) 
code  -  Malibu  Research  has  produced  many  high  fidelity  target  generating 
environments  for  RADARs  in  the  past.  The  RSG  development  cost  would  be  greatly 
reduced  if  the  code  development  cycle  could  be  foreshortened  by  using  existing 
modules  developed  for  various  incarnations  of  the  RES. 


Hardware  Approach  for  the  RSG 


PMC  site 


PMC  compute  module 
G3-300MHZ  /  VxWorks 


The  hardware  COTS  configuration  that  best  addresses  the  requirements  of  the  RSG 
(faster  speed  is  better)  and  is  consistent  with  the  4  guidelines  indicat^  is  shown  above.  There 
is  one  Canadian  company  that  potentially  provides  a  complete  hardware  solution  for  the  RSG... 
Spectrum  Signal  Processing  Inc.  in  Burnaby,  British  Columbia. 


The  TMS320-C6X  processor  was  the  engine  that  was  selected.  This  Texas  Instruments 
product  has  a  basic  1.6  GIPs  (Giga-instruction/sec)  benchmark  for  the  floating  point  product, 
which  is  due  to  hit  the  COTS  market  in  6/99.  The  pin  compatible  integer  version  of  this 
product  is  supported  by  Spectrum  Signal  Processing  Inc.  at  present  with  a  family  of  available 
boards  ranging  from  a  single  processor  board  to  the  quad  processor  board  shown  above. 

These  family  of  boards  support  the  industry  standard  PMC  (PCI  Mezzanine  Card)  site  which 
allows  addition  of  a  genersd  puipose  processor  board  (Power  PC  G3  or  G4  being  the  most 
likely  candidate)  with  a  wide  bus  bandwidth  (132  MB/s)  interconnect.  Also,  there  are 
proprietary  PEM  (Processor  Expansion  Module)  sites  available  on  the  board  to  allow  direct 
plug  in  of  the  IF  conversion  hardware  at  even  a  higher  data  bandwidth  (400  MB/s).  When  the 
floating  point  silicon  becomes  available,  the  same  family  of  boards  and  software  tools  are 
expected  to  handle  the  development  since  the  floating  point  processor  is  an  on-chip  upgrade. 


The  RSG  tradespace  has  no  hard  boundaries.  Signal  fidelity  is  the  riguie  of  merit.  The 
assessment  of  required  compute  power  has  been  made  based  on  the  advertised  benchmarks  for 
FFT  processes  and  arithmetic  computations  in  the  floating  point  version  of  the  TI  DSP 
processor  (66  uS  for  a  1024  point  con^lex  FFT  and  5  nS  for  a  complex  multiply/add).  For  the 
RADAR  model  presented  in  the  rirst  progress  rq)ort,  the  longest  search  ranges  (300  Km) 
require  the  most  compute  power. 

The  s^proach  proposed  for  the  RSG  required  FFTs  to  be  performed  as  a  means  to 
effect  waveform  convolution  with  the  live  range  trace  data.  After  considering  all  the 
computations  that  had  to  be  done  to  fill  the  range  trace  buffer  in  the  IF  conversion  module,  a 
requirement  of  2  TI  DSP  chips  was  deemed  necessary  for  each  RADAR  channel.  One  chip  is 
cq)able  of  providing  the  range  trace  for  each  and  eveiy  pulse  (at  a  1  MSPS  rate)  with 
t^proximately  25%  margin  and  the  second  chip  is  used  to  do  the  scene  management 
calculations  with  approximately  50%  margin.  This  means  that  the  board  shown  above  will 
support  2  RADAR  channels  (of  the  described  in  the  first  progress  report)  from  a 
computational  standpoint. 

Given  the  2  processor  availability,  a  prior  knowledge  of  RADAR  operation  was 
required  to  be  3mS  in  order  to  preserve  the  planned  tidelity  as  indicated  earlier.  This  assumed 
that  all  the  environment  generation  had  been  done  off-line  and  existed  in  a  data  file.  As  the 
3mS  is  reduced,  the  RSG  will  forego  some  of  the  fidelity  of  the  "live”  data.  For  example, 
most  RADARs  use  the  first  few  pulses  to  provide  “qiace  fill”  functions  to  prime  the  clutter 
canceling  process.  The  RSG  would  use  this  time  to  perform  the  required  processing  without 
too  much  impact  on  the  RADAR.  The  “^ace  fill”  function  in  the  MG  is  addressed  simply  by 
computing  the  correct  ambiguous  range  and  placing  clutter  returns  accordingly. 

At  some  point,  if  the  live  data  bandwidth  significantly  increases  for  example,  the  RSG 
processing  will  be  re-allocated  to  include  the  other  2  processors  on  the  board,  and  then  each 
quad  DSP  processor  board  will  be  able  to  support  a  single  data  channel. 

A  US  based  company,  Echotek  Corp.  in  Huntsville,  AL  provides  the  class  of  hardware 
required  by  the  RSG,  for  the  PEM  site.  In  initial  conversations,  Echotek  has  indicated 
willingness  to  create  custom  designs  for  specific  {^plications  as  would  be  required  by  the  RSG. 

The  dettuls  of  this  hardware  configuration  are  as  follows: 

Processing  power: 

C6201  (fixed  point  processor)  16(X)MIPS  @  200MHz 

C6701  (floating  point  version)  same 

The  quad  board  identified  above  contains  4  ea.  Of  these  processors 

Data  infrastructure: 

PEM  (Processor  Expansion  Module)  bus:  400MB/S  to  each  C62 
Will  support  -  FPDP  (Front  Panel  Data  Port)  protocol 
The  IF  conversion  hardware  is  planned  to  be  attached  to  this  interface 


PMC  (PQ  Mezzanine  Card)  bus:  132MB/S 

Will  support  -  RACEway  &  FPDP  protocols 

Available  memory  on  the  quad  DSP  board: 

16MB  SDRAM  (Synchronous  Dynamic  RAM)  per  DSP  chip 

2MB  SBSRAM  (Synchronous  Burst  Dynamic  RAM)  accessible  to  all  DSP  chips 

Chassis  selection: 

The  VME  standard,  which  has  been  around  for  a  long  time  is  in  the  process  of  being 
replaced  with  “Compact  PCI  (cPCl)”.  The  inq}lementation  of  this  new  ^proach  is  similar  to 
the  VME  in  size,  however  the  bus  protocol  is  the  same  as  PCI,  which  was  developed  through 
the  Personal  Computer  market. 

There  are  several  chassis  manufacturers  that  provide  cPCI  chassis  solutions  for  the 
proposed  processor.  A  local  distributor  is  the  most  likely  vendor  choice  for  this  item  since  the 
technical  complexity  of  a  chassis  is  minimal  and  the  benefits  of  having  the  vendor  in  close 
proximity  pay  large  dividends  when  a  problem  is  encountered. 

The  proposed  chassis  is  distributed  by  a  local  company,  “One  Stop  Systems”  and  is 
shown  below: 


This  chassis  was  chosen  with  the  conscious  knowledge  that  the  RSG  might  require 
expansion.  The  maximum  available  slots  (16)  was  considered  a  requirement  although  if  a  card 
count  is  made  with  the  proposed  target  RADAR  (in  the  1“  progress  report),  an  8  slot  chassis 
will  suffice. 

The  card  shown  installed  in  the  center  of  the  chassis  is  the  host  PC  computer  which  will 
be  required  for  the  User  interface  portion  of  the  RSG.  This  PC  host  also  serves  as  a  bridge 


between  the  2  halves  of  the  chassis  which  is  fabricated  as  2  individual  8  slot  sub-chassis 
components...  also  for  maximum  flexibility. 


Details  of  the  chassis  selection  are  presented  below: 

Rack  mount  enclosure  with  fans 
[1]  350  watt  modular  power  supply 
16-slot  cPCI  backplane  with  rear  I/P  support 
300MHz  Pentium  II  CPU  board,  including: 

bridge  interface  between  the  2  halves  of  the  overall  chassis 
128  MB  SDRAM 

VGA,  keyboard,  mouse,  Coml  &  ethemet  connectors  on  face  plate 
One  PMC  interface 

3.2GB  hard  disk  and  floppy  drive  mezzanine 
40X  CD-ROM  drive  wiA  vertical  holder 
WindowsNT  pre-loaded  on  the  hard  disk 
Dimensions:  19.0”  wide,  15.75”  tall,  and  11.5”  deep 


Digital  VO  from  RADAR 


Power  supply 


An  overall  interconnection  of  the  RSG  components  has  been  shown  above.  The 
components  that  are  indicated  can  be  fully  serviced  by  the  350W  power  supply  that  is  provided 
by  the  chassis  manufacturer.  3.3  Volt  low  power  silicon  allows  a  significant  reduction  in 
power  consumption  on  the  part  of  the  DSP  assets,  which  have  traditionally  been  the  power 
hungry  con^nents  in  real  time  systems. 

A  general  purpose  computer  card  (Power  PC  r/t  master)  was  planned  into  the 
architecture  since  the  DSP  chips  are  pipelined  processors.  Their  efficiency  at  context 
switching  operations  may  preclude  the  need  for  the  “r/t  master”  processor  which  was  intended 
to  provide  help  in  the  area  of  scene  parameter  translation  from  the  database  to  the  range  trace 
portion  of  the  processing  chain. 

The  digital  I/O  portion  of  the  RSG  is  intended  to  provide  the  command  and  status 
interface  to  the  RADAR.  As  such,  diis  card  represents  the  portion  of  the  RSG  that  is  subject 
to  change  dq)ending  on  the  eventual  t^plication  of  the  RSG.  The  overall  design  ^proach  will 
be  CPLD  (Complex  Programmable  Logic  Device)  based  and  will  have  the  anticipated  interface 
to  accommodate  up  to  4  streams  of  serial  data  or  32  bit  wide  parallel  transfers. 


Up  to  6  channels  can  be  supported  with  the  configuration  proposed  above.  The  COTS 
approach  allows  the  various  components  to  be  simply  plugged  together  without  much 
overhead.  The  only  variables  are  the  RADAR  specific  connections. 

An  overall  enclosure  to  house  the  RSG  is  planned  and  will  be  addressed  in  detail  in 
subsequent  phases  of  this  SBIR.  This  overall  enclosure  will  serve  as  the  physical  interface 
between  the  RADAR  connections  and  the  RSG  I/O.  Interconnections  within  the  RSG  will  be 
planned  with  integration  and  troubleshooting  as  a  goal,  but  will  be  constrained  by  size. 
RADAR  connections  on  the  other  hand  are  completely  defined  by  the  specific  RADAR. 

3.0  Plan  for  next  month 

a)  Document  acceptable  data  interface  formats  from  the  various  modeling 
components  that  contribute  to  the  RSG 

b)  Identify  potential  application  (RADAR  development,  testing,  training  etc...)  and 
target  RADAR  where  the  Malibu  Research  approach  to  the  RSG  may  be  used. 

5.0  Anticipated  Problems: 


None 


